Scenari Migrazione V2T

NSX-v come tecnologia sta per raggiungere l’EOS o End of Support il prossimo anno, precisamente gennaio 2022: https://kb.vmware.com/s/article/2149616, questo significa che il tempo per pensare alla migrazione oramai è agli sgoccioli.

In questo articolo voglio riassumere quello che è stato, e che è effettuare una migrazione NSX-v a NSX-t, quali sono gli scenari, quale scegliere ed il perché.

Innanzi tutto iniziamo a parlare di NSX-T del perché non è solo il successore di NSX-V ma è senz’ombra di dubbio un evoluzione della tecnologia SDN di mamma VMware.

NSX-T utilizza in primis un diverso tipo di protocollo di Overlay chiamato GENEVE (ce ne sono anche altri tra cui VXLAN in NSX-v e NVGRE), se avete interesse nel capire perché questo protocollo vi consiglio la lettura:
https://www.techtarget.com/searchnetworking/tip/GENEVE-primer-The-answer-to-network-virtualization-interoperability

Principalmente Geneve come protocollo perchè è attualmente uno standard Internet Draft IETF che si basa sui concetti VXLAN/STT/NVGRE per fornire una maggiore flessibilità in termini di estensibilità del piano dati. Geneve consente inoltre a qualsiasi fornitore di aggiungere i propri metadati nell’intestazione del tunnel con una semplice modalità Type-Length-Value (TLV) che è dinamica.

Interessante video su Geneve come potrocollo utilizzato dagli open vSwitch (Open vSwitch Geneve)

Altro punto a favore di NSX-T è multi-hypervisor, può essere installato su ESXi e su KVM ed inoltre è Multi-Cloud: può far parte di una configurazione standard on-prem ma anche espandere un infrastruttura verso il cloud, o gestire più ambienti separati ma da un unico pannello (Federation).

Ma a parte tutto questo la parte principale del perché bisogna effettuare questo passaggio da NSX-V a NSX-T è sicuramente la Sicurezza.
NSX-T ha un migliore motore che gestisce il firewall distribuito o DFW, le rule sono implementate “finalmente” in modo ottimale. La piattaforma NSX-T con il suo  firewall può gestire i Containers implementando la microsegmentation e quindi lo Zero Trust anche per questo tipo di workload.
Ultimo ma non ultimo la possibilità di mettere in campo nuove funzionalità di sicurezza:

• URL Analysis Workflow
• NSX Container Plug-in
• Service Insertion and Service Chaining
• North-South Service Insertion
• Guest Introspection
• Intrusion Detection and Prevention
• IDFW (Identity Firewall)
• NSX Intelligence

Queste sono solo alcune, NSX ad ogni nuova versione vengono costantemente aggiunte migliorie e funzionalità.

Insomma se dovete partire con la tecnologia SDN il punto di partenza NSX-T ma se invece fate parte di chi ha già implementato questo tipo di tecnologia con NSX-v bisogna pensare a quali opzioni sono possibili per quanto riguarda la migrazione.

A dispetto del meme sopra, nessuna paura!  Sul molti blog come questo e sul techzone di VMware vengono spiegati molto bene i tre possibili scenari di migrazione che vedete nell’immagine qui sotto.

Gli scenari visibili sopra sono quelli generalmente disponibili per questo tipo di migrazione che ripeto, dipende sempre dall’ambiente, ma andiamo ad analizzarli un po’ più nello specifico.

IN PLACE
Questo tipo di migrazione utilizza il Migrator Coordinator Tool che è già presente all’interno dell’NSX-T Manager dalla versione 2.4.
Il tool importa una configurazione esistente (NSX-v) è applica questa configurazione su NSX-t all’interno di un flusso automatizzato che similmente ad un upgrade di versione si occuperà di fare tutte le operazioni necessarie per convertire un ambiente NSX-v in NSX-t con un “piccolo” downtime.
Il tool hai dei check di pre-migrazione che certificano che una determinata configurazione può essere portata su NSX-T (non tutte le configurazioni sono compatibili), si occuperà inoltre di effettuare tutte quelle operazioni che servono per trasformare l’ambiente mettendo in Maintenance Mode gli host, facendo vmotion prima di rimpiazzare i VIBs.  Più informazioni sono disponibili al seguente link.

CO-EXIST
Con questo tipo di scelta invece l’idea è costruire un ambiente NSX-t parallelo a quello attualmente in uso, in realtà in questo scenario la migrazione non avviene poichè l’installazione di tutte le nuove app andreanno sul nuovo ambiente mentre si attende che le vecchie applicazioni su NSX-v finiscano il loro ciclo di utilizzo/vita (o vengano rimpiazzate con nuovi app in NSX-T). Ovviamente in questo caso è chiaro che il carico di lavoro per la gestione raddoppia, poiché bisognerà mantenere operativamente due ambienti anziché uno. (Con tutte le complicanze del caso)

LIFT AND SHIFT
Ultimo ma non ultimo lift and shift che è uno scenario che inizia come il precedente quindi con greenfield NSX-T in cui poi andremo effettivamente a migrare i nostri workload da V a T. Anche qui in alcuni casi il Migrator Coordinator può venirci in aiuto effettuando alcune configurazioni, in questo caso si può utilizzare il tool gratuito presente all’interno di NSX-T che nella sua prima release (in aggionamento) permetteva di migrare regole firewall e gruppi via API, non i tags applicati alle VMs, e non fa inoltre il movimento delle VM da un ambiente ad un altro. Quindi copertura parziale in questo caso. Gli altri casi che si adattano a questo tipo di migrazione è la possibilità di utilizzare scripts autoprodotti che permettono di fare questo tipo di migrazione secondo gli eventuali requisiti di migrazione, lasciano se si ha l’expertise per farlo grande spazio alla customizzazione.
L’ultima possibilità a questo tipo di migrazione invece è la possibilità di utilizzare strumenti di terze parti come SPJ’s clTopus e RestNSX MAT. Entrambi questi tool (il sottoscritto conosce abbastanza bene MAT) sono in grado di copiare “completamente” la configurazione di NSX-v e copiarla/convertirla in oggetti NSX-T, quindi possibilità di replicare quasi al 100% l’attuale.

RestNSX Mat
(E’ il tool che conosco di più tra i due quindi mi concentrerò a spiegare velocemente come funziona)

RestNSX  è in grado di collezionare tutte le informazioni di un ambiente NSX-v, verificandone le configurazione e transformando o copiando ogni oggetto da V a T. MAT ha diverse modalità di utilizzo a seconda dei casi, è in grado di portare solo una parte di configurazione come il firewall e lasciare il resto delle configurazione come il routing all’utente. Vi sono molteplici scelte di configurazione che si adattano a molteplici richieste di migrazione e così facendo è in grado di gestire tutte le diverse customizzazioni per supportare le migrazioni di ogni ambiente NSX-v. Inoltro è in grado di fornire report prima di effettuare la migrazione, così da verificare l’ambiente da migrare ed effetuare un assestment nel caso ci sia bisogno.  La possibilità di fare rollback è inoltre utilissima in caso di testing potendo così provare più volte lo scenario di migrazione e poi riportare tutto alla configurazione pulita. Insomma un tool molto potente in grado di aiutare a semplificare di moltissimo lo scenario di migrazione. Sul sito si possono trovare le 4 fasi principali di migrazione con MAT:
1)Define Data Sources
2) Collect
3) Transform
4) Migrate and Post Migratio Task (Tags, Cleanup)

Nel video qui sotto potete invece vedere ed ascoltare più nel dettaglio gli scenari di Migrazione V2T da parte di 27 Virtual (Partner VMware focalizzato su servizi avanzati con una grande conoscenza di NSX) ed anche una demo di come RestNSX MAT aiuta la migrazione V2T.

Ovviamente questa è solo un piccola overview di cosa significa migrare da NSX-v a NSX-t, vi sono innumerevoli parti tecniche che devono essere colmate e che non è possibile fare in un singolo articolo sul blog.  Se l’argomento è di interesse vi consiglio la lettura del seguente documento presente sulla techzone di VMware che spiega nel dettaglio l’utilizzo di alcuni parametri avanzati a supporto della migrazione.