NSX-v vs NSX-T: confronto completo
La virtualizzazione ha apportato cambiamenti rivoluzionari al modo in cui vengono realizzati i data center. La maggior parte dei data center moderni utilizza la virtualizzazione hardware e effettua l’implementazione di server fisici come hypervisor per eseguire VM su tali server. Questo approccio migliora la scalabilità, la flessibilità e l’efficienza in termini di costi del data center. VMware è uno dei principali attori nel mercato della virtualizzazione e i suoi prodotti godono di grande prestigio nel settore IT; l’hypervisor VMware ESXi e VMware vCenter sono componenti ampiamente conosciuti della soluzione di virtualizzazione VMware vSphere.
La rete è una componente cruciale di ogni data center, compresi quelli virtualizzati, e se avete requisiti per reti di grandi dimensioni e configurazioni di rete complesse per il vostro data center virtualizzato, prendete in considerazione l’utilizzo del Software-Defined Networking (SDN). Il Software-Defined Networking è un’architettura che mira a rendere le reti agili e flessibili. L’obiettivo dell’SDN è migliorare il controllo della rete consentendo alle aziende e ai fornitori di servizi di rispondere rapidamente ai mutevoli requisiti aziendali. VMware ha a cuore i propri clienti e fornisce la soluzione VMware NSX per la creazione di reti definite dal software. Il post del blog di oggi tratta di VMware NSX ed esplora la differenza tra VMware NSX-v e VMware NSX-T.
Che cos’è VMware NSX e come si utilizza?
VMware NSX è una soluzione di virtualizzazione di rete che consente di creare reti definite dal software (SDN) in data center virtualizzati. Proprio come le VM sono astratte dall’hardware fisico dei server, le reti virtuali – inclusi switch, porte, router, firewall ecc. – vengono costruite nello spazio virtuale. Le reti virtuali vengono fornite e gestite indipendentemente dall’hardware sottostante. Le VM sono collegate alle porte virtuali di switch virtuali; la connessione tra le reti virtuali avviene tramite router virtuali e le regole di accesso vengono configurate sui firewall virtuali. In alternativa, è disponibile anche il bilanciamento del carico di rete. VMware NSX è il successore di VMware vCloud Networking & Security (vCNS)e di Nicira NVP, acquisita da VMware nel 2012.
Microsegmentazione
Quando si utilizza un approccio tradizionale per configurare l’accesso tra più reti in un ambiente virtuale, solitamente viene effettuata l’implementazione di un router fisico o di un gateway perimetrale in esecuzione su una macchina virtuale, sebbene questo approccio non sia particolarmente veloce né conveniente. VMware ha implementato il concetto di microsegmentazione in NSX utilizzando un firewall distribuito integrato nel nucleo dell’hypervisor. I criteri di sicurezza e i parametri di interazione di rete relativi a indirizzi IP, indirizzi MAC, VM, applicazioni e altri oggetti vengono tutti definiti in questo firewall distribuito. Le regole possono essere configurate utilizzando oggetti quali utenti e gruppi di Active Directory, qualora NSX sia implementato all’interno dell’azienda in cui viene utilizzato un controller di dominio Active Directory (ADDC). Ogni oggetto può essere considerato come un microsegmento all’interno del proprio perimetro di sicurezza della rete corrispondente, dotata di una propria DMZ (zona demilitarizzata).
Il firewall distribuito consente di segmentare entità del data center virtuale come le VM. La segmentazione può basarsi su nomi e attributi delle VM, identità degli utenti, oggetti vCenter quali data center e host, oppure su attributi di rete tradizionali quali indirizzi IP, gruppi di porte e così via.
Il componente Edge Firewall consente di soddisfare i requisiti chiave di sicurezza perimetrale, quali la creazione di DMZ basate su strutture IP/VLAN, l’isolamento tra tenant nei data center virtuali multi-tenant, la traduzione degli indirizzi di rete (NAT), le VPN dei partner (extranet) e le VPN SSL basate sugli utenti.
Se una VM viene migrata da un host a un altro — da una sottorete a un’altra — le regole di accesso e i criteri di sicurezza vengono adattati in base alla nuova ubicazione. Se un server di database è in esecuzione su una macchina virtuale (VM) migrata, le regole impostate per tale VM nel firewall continueranno a funzionare anche dopo il completamento della migrazione verso un altro host o una rete diversa, consentendo al server di database di accedere al server applicativo in esecuzione sulla VM che non è stata migrata. Questo è un esempio concreto di maggiore flessibilità e automazione nell’utilizzo di VMware NSX. NSX può rivelarsi particolarmente utile per i provider cloud e per le grandi infrastrutture virtuali. VMware offre due tipi di piattaforma di rete definita dal software NSX: NSX-v e NSX-T.
NSX per vSphere (NSX-v) è strettamente integrato con VMware vSphere e l’implementazione del VMware vCenterè obbligatoria. VMware NSX-v è specifico per gli ambienti con hypervisor vSphere ed è stato sviluppato prima di NSX-T.
NSX-T (NSX-Transformers) è stato progettato per diverse piattaforme di virtualizzazione e ambienti multi-hypervisor e può essere utilizzato anche nei casi in cui NSX-v non sia applicabile. Mentre NSX-v supporta l’SDN solo per VMware vSphere, NSX-T supporta anche lo stack di virtualizzazione di rete per KVM, Docker, Kubernetes e OpenStack, oltre ai carichi di lavoro nativi di AWS. VMware NSX-T può essere implementato senza un vCenter Server ed è adottato per sistemi di elaborazione eterogenei.
Gli scenari principali per l’utilizzo di NSX-v sono elencati nella tabella sottostante. La tabella è suddivisa in tre righe, una delle quali descrive la categoria dello scenario. Gli scenari per l’utilizzo di NSX-T sono evidenziati in grassetto.
| Sicurezza | Automazione | Continuità delle applicazioni |
| Microsegmentazione | Automazione IT | Ripristino di emergenza |
| Sicurezza degli utenti finali | Cloud per sviluppatori | Pooling multi-data center |
| DMZ ovunque | Infrastruttura multi-tenant | Cross-cloud |
Componenti NSX
I componenti principali di VMware NSX sono NSX Manager, i controller NSX e i gateway NSX Edge.
NSX Manager è un componente centralizzato di NSX utilizzato per la gestione delle reti. NSX Manager può essere implementato come VM su uno dei server ESXi gestiti da vCenter (da un modello OVA). Nei casi in cui si utilizzi NSX-v, NSX Manager può funzionare con un solo vCenter Server, mentre NSX Manager per NSX-T può essere implementato come VM ESXi o KVM e può funzionare con più server vCenter contemporaneamente. NSX Manager per vSphere si basa su Photon OS (simile a vCenter Server Appliance).
NSX-T Manager funziona sul sistema operativo Ubuntu.
Controller NSX . Il controller NSX è un sistema distribuito di gestione dello stato utilizzato per sovrapporre tunnel di trasporto e controllare reti virtuali; può essere distribuito come macchina virtuale su hypervisor ESXi o KVM. Il controller NSX gestisce tutti gli switch logici all’interno della rete e gestisce le informazioni relative a macchine virtuali, host, switch e VXLAN. La presenza di tre nodi di controllo garantisce la ridondanza dei dati in caso di guasto di un nodo del controller NSX.
NSX Edge è un servizio gateway che fornisce alle macchine virtuali l’accesso alle reti fisiche e virtuali. NSX Edge può essere installato come router virtuale distribuito o come gateway di servizi. È possibile fornire i seguenti servizi: instradamento dinamico, firewall, Network Address Translation (NAT), Dynamic Host Configuration Protocol (DHCP), rete privata virtuale (VPN), bilanciamento del carico e alta disponibilità.
Opzioni di implementazione
Il concetto di implementazione è piuttosto simile sia per NSX-v che per NSX-T. Per implementare NSX è necessario eseguire i seguenti passaggi:
- Implementare NSX Manager come macchina virtuale su un host VMware ESXi utilizzando una virtual appliance. Assicurarsi di registrare NSX Manager su VMware vCenter (per NSX-v). Se si utilizza NSX-T, NSX Manager può essere implementato come virtual appliance su un host KVM, poiché VMware NSX-T consente di creare un cluster di NSX Manager.
- Distribuire tre controller NSX e creare un cluster di controller NSX.
- Installare
VIBs(moduli del kernel) sugli host ESXi per abilitare il firewall distribuito, il routing distribuito e VXLAN se si utilizza NSX-v. Se si utilizza NSX-T, i moduli del kernel devono essere installati anche sugli hypervisor KVM. - Installare NSX Edge come VM su ESXi (per NSX-v e NSX-T). Se si utilizza NSX-T e non è possibile installare Edge come VM su ESXi, Edge può essere implementato su un server fisico. L’implementazione di Edge come VM su hypervisor KVM non è attualmente supportata (per NSX-T v.2.3). Se è necessario effettuare l’implementazione di Edge su un server fisico, controllare l’elenco di compatibilità hardware (importante per CPU e schede di rete) prima di procedere.
Funzionalità comuni di NSX
Esiste una serie di funzionalità disponibili per entrambi i tipi di NSX.
Le funzionalità comuni per NSX-v e NSX-T sono:
- Virtualizzazione di rete basata su software
- Overlay basato su software
- Routing distribuito
- Firewall distribuito
- Automazione basata su API
- Monitoraggio e statistiche dettagliate
Si noti che le API sono diverse per NSX-v e NSX-T.
Licenze
Il sistema di licenze è lo stesso per entrambi i tipi di NSX, in quanto offre maggiore flessibilità e universalità. Ad esempio, è possibile ordinare una licenza per l’utilizzo di NSX per vSphere e, qualora si apportassero modifiche all’infrastruttura e fosse necessario effettuare l’implementazione di NSX-T, è possibile utilizzare la licenza ottenuta per ESXi-v. NSX è NSX: non vi è alcuna distinzione dal punto di vista delle licenze, poiché anche le edizioni delle licenze sono le stesse.
Incapsulamento overlay
L’incapsulamento overlay per le reti virtuali viene utilizzato per astrarre le reti virtuali trasportando le informazioni del livello 2 sul livello 3. Viene creata una rete logica di livello 2 sopra le reti di livello 3 esistenti (reti IP) su un’infrastruttura fisica esistente. Di conseguenza, due VM possono comunicare tra loro attraverso la rete, anche se il percorso tra le VM deve essere instradato. Una rete fisica può essere definita rete underlay.
VXLAN vs GENEV
NSX-v utilizza il protocollo di incapsulamento VXLAN, mentre NSX-T utilizza GENEVE che è un protocollo più moderno.
VXLAN . Per VXLAN viene utilizzato un incapsulamento MAC su IP e il principio di funzionamento dell’isolamento di rete differisce dalla tecnica VLAN. La VLAN tradizionale ha un numero limitato di reti, pari a 4094 secondo lo standard 802.1q, e l’isolamento di rete avviene sul livello 2 di una rete fisica aggiungendo 4 byte alle intestazioni dei frame Ethernet. Il numero massimo di reti virtuali per VXLAN è 2^24. In questo caso, l’identificatore di rete VXLAN viene utilizzato per contrassegnare ciascuna rete virtuale. I frame di livello 2 della rete overlay sono incapsulati all’interno dei datagrammi UDP trasmessi su una rete fisica. Il numero di porta UDP in questo caso è 4789.
L’intestazione VXLAN è composta dalle seguenti parti.
- 8 bit sono utilizzati per i flag. Il flag I deve essere impostato a 1 per rendere valido un
VXLAN Network ID (VNI). Gli altri 7 bit sono campi R riservati e devono essere impostati a zero durante la trasmissione. I campi R impostati a zero vengono ignorati al momento della ricezione. VXLAN Network Identifier (VNI), noto anche comeVXLAN Segment ID, è un valore a 24 bit utilizzato per determinare la singola rete overlay utilizzata per la comunicazione tra le VM.- I campi riservati (a 24 bit e a 8 bit) devono essere impostati a zero e ignorati al momento della ricezione.
La dimensione dell’intestazione VXLAN è fissa ed è pari a 8 byte. Per VXLAN si raccomanda l’uso di frame Jumbo con MTU impostato a 1600 byte o più.
GENEVE. L’intestazione GENEVE è molto simile a quella VXLAN e presenta la seguente struttura:
- Un’intestazione di tunnel compatta è incapsulata in UDP su IP.
- Viene utilizzata una piccola intestazione di tunnel fissa per fornire informazioni di controllo, oltre a un livello base di funzionalità e interoperabilità.
- Sono disponibili opzioni a lunghezza variabile per consentire l’implementazione di innovazioni future.
La dimensione dell’intestazione GENEVE è variabile.
NSX-T utilizza GENEVE (GEneric NEtwork Virtualization Encapsulation) come protocollo di tunneling che preserva le tradizionali funzionalità di offload disponibili sulle schede di rete (NIC) per garantire le migliori prestazioni. È possibile aggiungere metadati aggiuntivi alle intestazioni overlay, il che consente di migliorare la differenziazione del contesto per l’elaborazione di informazioni quali la telemetria end-to-end, il tracciamento dei dati, la crittografia, la sicurezza ecc. a livello di trasferimento dei dati. Le informazioni aggiuntive nei metadati sono denominate TLV (Tipo, Lunghezza, Valore). GENEVE è sviluppato da VMware, Intel, Red Hat e Microsoft. GENEVE si basa sui migliori concetti dei protocolli di incapsulamento VXLAN, STT e NVGRE .
Il valore MTU per i frame Jumbo deve essere di almeno 1700 byte quando si utilizza l’incapsulamento GENEVE , a causa del campo metadati aggiuntivo di lunghezza variabile per le intestazioni GENEVE (come ricorderete, per VXLAN si utilizza un MTU pari o superiore a 1600).
NSX-v e NSX-T non sono compatibili a causa della differenza nell’incapsulamento overlay spiegata in questa sezione.
Reti di livello 2
Ora che sapete come vengono incapsulati i frame Ethernet virtuali di livello 2 sulle reti IP, è giunto il momento di esplorare l’implementazione delle reti virtuali di livello 2 per NSX-v e NSX-T.
Nodi di trasporto e switch virtuali
I nodi di trasporto e gli switch virtuali rappresentano i componenti di trasferimento dati di NSX.
Nodo di trasporto (TN) è il dispositivo compatibile con NSX che partecipa alla trasmissione del traffico e all’overlay di rete NSX. Per poter fungere da nodo di trasporto, un nodo deve contenere un hostswitch. NSX-v richiede l’utilizzo dello switch virtuale distribuito di VMware vSphere (VDS) come di consueto in VMware vSphere. Gli switch virtuali standard non possono essere utilizzati per NSX-v.
NSX-T presuppone che sia necessario effettuare l’implementazione di uno switch virtuale distribuito NSX-T (N-VDS). Open vSwitches (OVS) vengono utilizzati per gli host KVM, mentre gli switch virtuali VMware vengono utilizzati per gli host VMware ESXi e possono essere impiegati a questo scopo.
N-VDS (switch virtuale distribuito, precedentemente noto come hostswitch) è un componente software di NSX presente sul nodo di trasporto, che esegue la trasmissione del traffico. N-VDS è il componente principale del piano dati dei nodi di trasporto che inoltra il traffico e possiede almeno un controller di interfaccia di rete (NIC) fisico. NSX Switches (N-VDS) dei diversi nodi di trasporto sono indipendenti ma possono essere raggruppati assegnando loro lo stesso nome per una gestione centralizzata.
Sugli hypervisor ESXi N-VDS viene implementato utilizzando VMware vSphere Distributed Switch tramite il modulo NSX-vSwitch caricato nel kernel dell’hypervisor. Sugli hypervisor KVM l’hostswitch è implementato dal modulo Open-vSwitch (OVS) .
Le zone di trasporto sono disponibili sia per NSX-v che per NSX-T. Le zone di trasporto definiscono i limiti della distribuzione delle reti logiche. Ogni zona di trasporto è collegata al proprio switch NSX (N-VDS). Le zone di trasporto per NSX-T non sono collegate ai cluster.
Esistono due tipi di zone di trasporto per VMware NSX-T a causa dell’incapsulamento GENEVE: Overlay o VLAN. Per quanto riguarda VMware NSX-v, una zona di trasporto definisce i limiti di distribuzione esclusivamente di VXLAN.
Modalità di replica degli switch logici
Quando due VM residenti su host diversi comunicano direttamente, il traffico unicast viene scambiato in modalità incapsulata tra due indirizzi IP degli endpoint assegnati agli hypervisor senza necessità di flooding. A volte, il traffico di rete di livello 2 generato da una VM deve essere diffuso in modo analogo al traffico di livello 2 nelle reti fisiche tradizionali, ad esempio se un mittente non conosce l’indirizzo MAC dell’interfaccia di rete della destinazione. Ciò significa che lo stesso traffico (broadcast, unicast, multicast) deve essere inviato a tutte le VM collegate allo stesso switch logico. Se le VM risiedono su host diversi, il traffico deve essere replicato su tali host. Il traffico broadcast, unicast e multicast è noto anche come traffico BUM.
Vediamo la differenza tra le modalità di replica per NSX-v e NSX-T.
NSX-v supporta la modalità Unicast, la modalità Multicast e la modalità Ibrida.
NSX-T supporta la modalità Unicast con due opzioni: Replica gerarchica a due livelli (ottimizzata, come per NSX-v) e replica Head (non ottimizzata).
La soppressione ARP riduce la quantità di traffico di broadcast ARP inviato sulla rete ed è disponibile per le modalità di replica del traffico Unicast e Ibrido. Pertanto, la soppressione ARP è disponibile sia per NSX-v che per NSX-T.
Quando una VM1 invia una richiesta ARP per conoscere l’indirizzo MAC di una VM2, la richiesta ARP viene intercettata dallo switch logico. Se lo switch dispone già della voce ARP relativa alla Rete di destinazione della VM2, lo switch invia la risposta ARP alla VM1. In caso contrario, lo switch invia la richiesta ARP a un controller NSX. Se il controller NSX contiene le informazioni relative al binding IP-MAC della VM, il controller invia la risposta con tale binding e quindi lo switch logico invia la risposta ARP alla VM1. Se sul controller NSX non è presente alcuna voce ARP, la richiesta ARP viene ritrasmessa sullo switch logico.
Bridging di livello 2 di NSX
Il bridging di livello 2 è utile per migrare i carichi di lavoro dalle reti overlay alle VLAN o per suddividere le sottoreti tra carichi di lavoro fisici e virtuali.
NSX-v: Questa funzione opera a livello di kernel di un hypervisor su cui è in esecuzione una VM di controllo.
NSX-T : A tale scopo viene creato un nodo NSX-bridge separato. I nodi NSX-bridge possono essere raggruppati in cluster per migliorare la tolleranza ai guasti dell’intera soluzione.
Nella VM di controllo NSX-v, la ridondanza veniva implementata utilizzando lo schema di alta disponibilità (HA). Una copia della VM è attiva mentre la seconda copia è in stand-by. Se la VM attiva subisce un guasto, può essere necessario un po’ di tempo per effettuare il passaggio tra le VM e caricare quella in stand-by rendendola attiva. NSX-T non presenta questo svantaggio, poiché per l’alta disponibilità (HA) viene utilizzato un cluster a tolleranza ai guasti anziché lo schema attivo/in stand-by.
Il modello di routing
Nei casi in cui si utilizza VMware NSX, vengono utilizzati i seguenti termini:
Traffico est-ovest si riferisce al trasferimento di dati in rete all’interno del data center. Questo nome viene utilizzato per questo particolare tipo di traffico poiché le linee orizzontali nei diagrammi indicano tipicamente il traffico della rete locale (LAN).
Traffico nord-sud si riferisce al traffico client-server o al traffico che si sposta tra un data center e una ubicazione esterna al data center (reti esterne). Le linee verticali nei diagrammi descrivono solitamente questo tipo di traffico di rete. Il router logico distribuito (DLR) è un router virtuale in grado di utilizzare percorsi statici e protocolli di routing dinamico quali OSPF, IS-IS o BGP.
Il termine “tenant” si riferisce a un cliente o a un’organizzazione che ottiene l’accesso a un ambiente sicuro e isolato fornito da un MSP (Managed Service Provider). Una grande organizzazione può avvalersi di un’architettura multi-tenant considerando ogni reparto come un singolo tenant. VMware NSX può rivelarsi particolarmente utile per fornire Infrastructure as a Service (IaaS).
Routing in NSX-v
NSX for vSphere utilizza il DLR (router logico distribuito) e il routing centralizzato. Su ciascun hypervisor è presente un modulo del kernel di routing che consente di eseguire il routing tra le interfacce logiche (LIF) sul router distribuito.
Consideriamo, ad esempio, lo schema di routing tipico di NSX-v, in presenza di un insieme di tre segmenti: macchine virtuali che eseguono database, macchine virtuali che eseguono server applicativi e macchine virtuali che eseguono server web. Le macchine virtuali di questi segmenti (azzurro, verde e blu scuro) sono collegate a un router logico distribuito (DLR) che, a sua volta, è collegato alle reti esterne tramite gateway perimetrali (NSX Edge).
Se si lavora con più tenant, è possibile utilizzare una struttura NSX Edge a più livelli, oppure ogni tenant può disporre di un proprio DLR dedicato e di una propria VM di controllo, quest’ultima residente nel cluster edge. Il gateway NSX Edge collega reti isolate (stub) a reti condivise (uplink) fornendo servizi gateway comuni quali DHCP, VPN, NAT, instradamento dinamico e bilanciamento del carico. Le implementazioni più comuni di NSX Edge includono la DMZ, le extranet VPN e gli ambienti cloud multi-tenant in cui NSX Edge crea confini virtuali per ciascun tenant.
Se è necessario trasmettere il traffico da una VM situata nel segmento A (blu) del primo tenant al segmento A del secondo tenant, il traffico deve passare attraverso il gateway NSX Edge. In questo caso non si ha un instradamento distribuito, poiché il traffico deve passare attraverso l’unico punto rappresentato dal gateway NSX Edge designato.
È inoltre possibile osservare il principio di funzionamento nello schema in cui i componenti sono suddivisi in cluster: cluster di gestione, cluster Edge e cluster di calcolo. In questo esempio, ogni cluster utilizza 2 host ESXi. Se due VM sono in esecuzione sullo stesso host ESXi ma appartengono a segmenti di rete diversi, il traffico passa attraverso il gateway NSX Edge che ha la sua ubicazione su un altro host ESXi del cluster Edge. Dopo l’instradamento, questo traffico deve essere ritrasmesso all’host ESXi su cui sono in esecuzione le VM di origine e di destinazione.
In questo caso, il percorso di trasmissione del traffico non è ottimale. Non è possibile sfruttare i vantaggi offerti dall’instradamento distribuito nel modello multi-tenant con gateway Edge, con conseguente aumento della latenza del traffico di rete.
Instradamento in NSX-T
NSX-T utilizza un modello di instradamento distribuito a due livelli per risolvere i problemi sopra descritti. Sia Tier0 che Tier1 vengono creati sui nodi di trasporto; il secondo non è necessario, ma è finalizzato a migliorare la scalabilità.
Il traffico viene trasmesso utilizzando il percorso più ottimale, poiché l’instradamento viene poi eseguito sull’hypervisor ESXi o KVM su cui sono in esecuzione le VM. L’unico caso d’uso in cui è necessario utilizzare un punto di routing fisso è quando ci si connette a reti esterne. Esistono nodi Edge separati distribuiti su server che eseguono hypervisor.
Servizi aggiuntivi come BGP, NAT e Edge Firewall possono essere abilitati sui nodi Edge, che a loro volta possono essere combinati in un cluster per migliorare la disponibilità. Inoltre, NSX-T offre anche un rilevamento più rapido dei guasti. In termini semplici, il modo migliore per distribuire il routing è il routing all’interno dell’infrastruttura virtualizzata.
Indirizzamento IP per le reti virtuali
Quando si configura NSX-v , è necessario definire uno schema di indirizzamento IP all’interno dei segmenti NSX. In questo caso devono essere aggiunti anche gli switch logici di transito che collegano i DLR e i gateway Edge. Se si utilizza un numero elevato di gateway Edge, è opportuno definire lo schema di indirizzamento IP per i segmenti collegati da tali gateway Edge.
NSX-T , tuttavia, non richiede queste operazioni. Tutti i segmenti di rete tra Tier0 e Tier1 ottengono automaticamente gli indirizzi IP. Non vengono utilizzati protocolli di routing dinamico, ma piuttosto rotte statiche; il sistema collega automaticamente i componenti, semplificando la configurazione; non è necessario dedicare molto tempo alla pianificazione dell’indirizzamento IP per i componenti della rete di servizio (transito).
Integrazione per l’ispezione del traffico
NSX-v offre l’integrazione con servizi di terze parti quali antivirus senza agente, firewall avanzati (firewall di nuova generazione), IDS (sistemi di rilevamento delle intrusioni), IPS (sistemi di prevenzione delle intrusioni) e altri tipi di servizi di ispezione del traffico. L’integrazione con i tipi di ispezione del traffico elencati viene eseguita a livello del kernel dell’hypervisor utilizzando un bus protetto VMCI (Virtual Machine Communication Interface).
NSX-T non offre queste funzionalità al momento.
Sicurezza
È possibile configurare firewall distribuiti a livello di kernel per NSX-v e NSX-T, che operano a livello di adattatore virtuale della VM. Le opzioni di sicurezza dello switch sono disponibili per entrambi i tipi di NSX, ma l’opzione “Rate-limit Broadcast & Multicast traffic” è disponibile solo per NSX-T.
NSX-T consente di applicare le regole in modo più granulare, con un conseguente utilizzo più razionale dei nodi di trasporto. Ad esempio, è possibile applicare regole basate sui seguenti oggetti: switch logico, porta logica, NSGroup. Questa funzione può essere utilizzata per ridurre la configurazione dei set di regole sugli switch logici, sulle porte logiche o sulle istanze di NSGroup, al fine di ottenere livelli più elevati di efficienza e ottimizzazione. È inoltre possibile risparmiare spazio di scala e cicli di ricerca delle regole, oltre a ospitare implementazioni multi-tenant e applicare regole specifiche per tenant (regole applicate alle carghe di lavoro del tenant appropriato).
Il processo di creazione e applicazione delle regole è piuttosto simile sia per NSX-v che per NSX-T. La differenza sta nel fatto che i criteri creati per NSX-T vengono inviati a tutti i controller, dove le regole vengono convertite in indirizzi IP, mentre in NSX-v i criteri vengono trasferiti immediatamente a vShield Firewall Daemon (VSFWD).
NSX-v vs NSX-T – Tabella comparativa
Ora che avete familiarizzato con le funzioni più interessanti di VMware NSX, riassumiamo le funzioni principali di NSX-v e NSX-T che sono state esaminate in questo post del blog, oltre a confrontarle nella tabella.
| NSX-v | NSX-T | |
| Stretta integrazione con vSphere | Sì | No |
| Funzionamento senza vCenter | No | Sì |
| Supporto per più istanze vCenter tramite NSX Manager | No | Sì |
| Fornisce reti virtuali per le seguenti piattaforme di virtualizzazione | VMware vSphere | VMware vSphere, KVM, Docker, Kubernetes, OpenStack, carichi di lavoro nativi AWS |
| Implementazione NSX Edge | VM ESXi | VM ESXi o server fisici |
| Protocolli di incapsulamento overlay | VXLAN | GENEVE |
| Switch virtuali (N-VDS) utilizzati | vSphere Distributed Switch (VDS) | Open vSwitch (OVS) o VDS |
| Modalità di replica degli switch logici | Unicast, Multicast, Ibrido | Unicast (a due livelli o Head) |
| Soppressione ARP | Sì | Sì |
| Routing distribuito a due livelli | No | Sì |
| Configurazione dello schema di indirizzamento IP per i segmenti di rete | Manuale | Automatico (tra Tier 0 e Tier 1) |
| Integrazione per l’ispezione del traffico | Sì | No |
| Firewall distribuito a livello di kernel | Sì | Sì |
Conclusione
NSX-v è la soluzione più ottimale se si utilizza esclusivamente un ambiente vSphere, mentre NSX-T può essere utilizzato non solo per vSphere ma anche per le piattaforme di virtualizzazione KVM, Docker, Kubernetes e OpenStack nell’ambito della creazione di reti virtuali. Non esiste una risposta univoca alla domanda su quale tipo di NSX sia migliore. La scelta tra NSX-v e NSX-T dipende dalle vostre esigenze e dalle funzioni offerte da ciascun tipo di NSX.
Il criterio di licenze di NSX è intuitivo: è sufficiente acquistare una sola licenza NSX, indipendentemente dal tipo di NSX che intendete utilizzare. In seguito è possibile installare NSX-T in un ambiente NSX-v o viceversa, a seconda delle esigenze, continuando a utilizzare la stessa licenza NSX.
È possibile realizzare il proprio data center software-defined con VMware utilizzando la soluzione NSX. VMware mette a disposizione funzioni di raggruppamento per garantire la continuità operativa, l’alta disponibilità e la tolleranza ai guasti; tuttavia, il backup delle macchine virtuali non sarà una misura superflua.
Eseguite regolarmente il backup delle vostre VM di produzione relative a diversi progetti e delle VM in esecuzione come componenti di VMware vSphere e VMware NSX (come vCenter, NSX Manager, NSX Controller, NSX Edge) al fine di proteggere i vostri dati. NAKIVO Backup & Replication può aiutarvi a creare il Backup di VMware in modo affidabile ed efficiente anche se utilizzate cluster.
