NSX-T: Part 1 – Another brick in the wall

Please use google translator button on the right to convert from Italian to English

 

Transormers

NSX-V

Giunti alla versione 6.4.4 e con un rilascio inziale datato a fine 2013, si può dire che questo prodotto ormai sia arrivato ad un buon livello di maturità. Ad ogni minor release, sono state introdotte nuove funzionalità con improvment più o meno importanti.
A mio avviso fra queste, potremmo citare l’introduzione degli Edge in modalità ECMP che hanno permesso a NSX di entrare nel mondo NFV e la possibilità di gestire ambienti più complessi in configurazione Cross vCenter/NSX tramite universal objects…ma il mercato e il mondo informatico nel corso di questi anni si è evoluto non permettendo a NSX-V di andare incontro ad alcune di queste nuove esigenze….

 

Decepticon

NSX-T, una nuova evoluzione nell’era degli SDN.

Risorto dalle presunte ceneri del “vecchio” NSX-MH (Multi Hypervisor), NSX-T si propone come un prodotto che non vuole limiti, un prodotto con grandi punti di forza che va incontro alle nuove esigenze di mercato.

In seguito alcuni di questi punti:

  • Integrazione con i Container
  • Integrazione con ambienti Cloud (AWS & Azure)
  • Gestione multi Hypervisor basati su KVM (Red Hat Enterprise, CentOS, Ubuntu & SLES) e vSphere

NSX-T Overview

Image source from NSX-T Reference Design Guide

NSX-T Architecture

Dal punto di vista architetturale, fino a NSX-T 2.3 non vi erano differenze sostanziali rispetto a NSX-V, infatti ritroviamo i seguenti componenti:

  • Management Plane – NSX-T Manager
  • Control Plane – Control Cluster Plane (CCP) & Local Control Plane (LCP)
  • Data Plane – N-VDS, NSX Edge (two form factor: VM & Bare Metal), L2 Bridge & Transport Nodes

NSX-Component

 

Con NSX-T 2.4 c’è stato un radicale cambio nella struttura del Management Plane che può essere messo in un cluster composto da 3 NSX Manager e l’integrazione del Central Control Plane direttamente all’interno dei 3 Manager.

Unified

 

Management Plane

NSX-T Manager è l’elemento centrale di configurazione di tutta l’infrastruttura, ospita la UI ed è l’entry-point per le REST API. Il manager è disponibile in 2 formati (ova e qcow2) e può essere installato in ambienti vSphere o KVM.

Control Plane

CCP – è l’elemento che effettua il push delle configurazioni generate dal Manager e gestisce la consistenza del Data Plane.
Dalla versione di NSX-T 2.4 le sue funzionalità sono erogate direttamente dai Manager.

LCP – Situato all’interno dei Transport Nodes (ESXi, KVM & Edge) si occupa di effettuare il push delle configurazioni ricevute dal CCP

NSX-Component2

Data Plane

N-VDS – è una tipologia di Distributed Switch indipendente dall’Hypervisor. Differentemente da NSX-V che costruisce l’Overlay Network su un DVS vSphere preconfigurato, NSX-T utilizza questi nuovi switch virtuali per effettuare il  forwarding traffic fra i Transport Nodes.
In ambienti ESXi gli N-VDS sono derivati dai DVS mentre in ambienti KVM sono derivati dagli Open vSwitch (OVS).

L2 Bridge – è un’applicance che effettua il bridge fra l’Overlay di NSX-T e una classica VLAN.

Transport Nodes – Possono essere suddivisi fondamentalmente in 2 categorie, gli Hypervisor (ESXi & KVM preparati e configurati da NSX-T ) che fanno forwarding traffic in modalità East-West e gli NSX Edge che effettuano forwarding North-South.

NSX Edge – Di fatto sono delle appliance che possono essere configurate in 2 distinte modalità, virtuali (esattamente come avviene in NSX-V) e bare metal.
Gli Edge virtuali possono essere installati solamente in environment vSphere, pertanto, in ambienti solamente KVM c’è la necessità di utilizzare la versione bare metal.
In configurazioni multi Hypervisor, i Transport Node KVM possono comunque utilizzare i servizi forniti dagli Edge virtuali installati su ambienti vSphere.
L’utilizzo di Edge bare metal può essere anche indicato in ambienti vSphere dove si ha la necessità di prestazioni sostenute (throughput e latenze) e/o in termini di failover response in caso di fault.
Un altro elemento di differenza è che contrariamente a quanto accade in ambienti NSX-V, gli Edge di NSX-T non forniscono solamente servizi come VPN, Firewall/NAT, DHCP, Load Balancer e Routing dinamico/statico ma forniscono direttamente i servizi di Ditributed Routing. In NSX-T, gli Edge fungono da Transport Node e hanno una terminazione  sull’Overlay, la quale gli permette di partecipare direttamante al routing distribuito.

Overlay Protocol

Senza andare troppo nei dettagli, NSX-T utilizza Geneve come Overlay Network (NSX-V utilizza VXLAN)

Ben Kenobi

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...