NSX Tier0 dedicato a clienti vCloud Director

da | Giu 4, 2024 | Security | 0 commenti

Introduzione

Il presente documento ha l’obiettivo di condurre uno studio breve sulla possibilità di assegnare un Tier0 a un cliente vCloud Director.

Stato dell’arte

Il documento nasce dall’idea di verificare l’effettiva possibilità di assegnare un Tier0 dedicato a un cliente che ne faccia richiesta e quali siano gli impatti per il CSP.

Si anticipa già che da una prima analisi della documentazione, la fattibilità risulta confermata (VMware Docs – vCD – Service Provider, s.d.; VMware Docs – vCD – Service Provider, s.d.).

Durante una lettura attenta della documentazione, tuttavia, sono state riscontrate alcune imprecisioni che sono state con successo risolte grazie al supporto del laboratorio.

Si evidenzia che l’analisi richiesta è relativa a una pre-analisi di fattibilità, soddisfatta già dal documento citato sopra (vedi Bibliografia), e che i test ulteriori hanno lo scopo di verificare in modo operativo la realizzabilità dichiarata dal venditore.

Molto sommariamente, di seguito si riporta un disegno di come è stato configurato l’ambiente e dei test eseguiti.

Si tratta quindi di capire se un’infrastruttura logica di questo tipo, comunemente implementata in una soluzione di risorse condivise, possa essere dedicata a un solo cliente.

Si evidenzia che in questo contesto non sono stati considerati nel dettaglio gli aspetti di sicurezza, oggetto di analisi più approfondite qualora si decidesse di perseguire la strada fino alla produzione.

A livello di NSX, è stato quindi configurato un T0 dedicato.

Le interfacce di uplink del T0 sono state collegate a una coppia di Edge Node dedicati aggregati in un Cluster Edge Dedicato.

Per scelte interne ricevute, si esclude a priori l’utilizzo dei VRF come router Tier 0 dedicato. La fattibilità di questo aspetto è stata, quindi, trascurata.

Nel caso di un T0 puro, è possibile procedere in due modi:

  1. Estendere il cluster Edge esistente.
  2. Creare un cluster Edge dedicato (fino a un massimo di 10 nodi) composto da almeno due nodi per avere alta affidabilità.

Questo è dovuto a un limite della soluzione di Network e Security adottata che supporta un solo T0 per Edge Node (EN). La scelta seguita in laboratorio è stata il deploy di due Edge aggiuntivi e la creazione di un nuovo Edge Cluster.

Per completezza è doveroso notare che se la soluzione VRF fosse percorribile, il vincolo sopra esposto sarebbe trascurabile, in quanto si avrebbero idealmente molti “Tier 0” (cento) su uno stesso Edge Cluster, ciascuno (VRF) assegnabile a ogni cliente che richiede un router dedicato, con un notevole risparmio di risorse.

Sebbene da documentazione sembri percorribile, non si vogliono destare false speranze in questo contesto, in quanto non sono sufficientemente indagate, ma vale la pena citarle al fine di percorrere tutte le possibili soluzioni possibili.

Terminata la configurazione lato NSX, il gateway creato è stato aggiunto come Network provider al tenant di interesse (in questo caso il tenant di prova “bveng”), ad esso dedicato, abilitando quindi la possibilità di impostare ed annunciare le proprie reti BGP da e verso i propri router.

Si ritiene inoltre importante evidenziare che le modifiche introdotte sono sufficienti per i test eseguiti, ma potrebbero non esserlo per una messa in produzione della soluzione. Tuttavia, non si ritiene che vi possano essere sostanziali compromissioni, se non dovute a decisioni interne e strategie particolari di cui non si è a conoscenza al momento della stesura di questa relazione.

Relativamente ai permessi necessari, è stato necessario creare un Right Bundle che, rispetto a quello di default, ha in aggiunta diritti evidenziati in figura.

È stato creato un Global Roles dedicato con i diritti del Right Bundle.

Aumentando i permessi dell’Organizational Administrator, è possibile permettere al tenant di crearsi autonomamente gli Edge Gateway (Tier 1). Questo lascerebbe piena autonomia al cliente di crearsi l’infrastruttura desiderata al di sotto del T0 senza dover interagire con il service provider. In sede di test, questa opzione non è stata considerata.

A differenza di quanto evidenziato nella documentazione (VMware Docs – vCD – Tenant User Guide, s.d.), di cui si riporta un estratto, è stato necessario creare un Organizational Administrator con il set di permessi creato sopra al fine di poter gestire lato vCloud Director le Route Advertisement ed il BGP.

Il router di peering in laboratorio è un VyOS versione 1.4.

Inoltre, è stato configurato NSX AVI per avere una soluzione di Load Balancer dedicata.

A differenza del Tier0 dedicato, in realtà non si è trovato un modo esplicito per dedicare le risorse al cliente, ma si ritiene che con una buona nomenclatura e una documentazione di provisioning precisa, non ci sono motivi per pensare alla presenza di possibili problemi a riguardo.

Ad esempio, nominando i SE Group come segue:

  • SE-Shared
  • SE-dedicated-

Applicate le configurazioni, è possibile quindi raggiungere da un “punto” dell’infrastruttura cliente un qualsiasi “punto” dell’infrastruttura Cloud (regole firewall permettendo).

Di seguito, un test di ping e successivamente di raggiungibilità web dalla VM 172.16.1.2 (esterna al vCloud Director ma appartenente all’infrastruttura del cliente ospitato nei DC Aruba) e il 192.168.1.14 appartenente alla rete di server pool, ad esempio, interna al vCloud.

Impatto sulle risorse necessarie

Le risorse aggiuntive richieste si basano principalmente su due fattori:

  1. La creazione del cluster Edge dedicato.
  2. La riservazione delle risorse per il Service Engine Group.

Relativamente al cluster Edge, il suo dimensionamento dipende dal throughput che si vuole erogare, secondo la seguente tabella (VMWare (R) – NSX Documentation, s.d.).

Un discorso analogo si applica ai SE. Nel caso si debbano riservare risorse al cliente, in funzione delle necessità e della disponibilità del Service Provider, è possibile fare riferimento alla guida ufficiale online (VMware (R) – NSX AVI Doc, s.d.) per trovare la soluzione adeguata.

Conclusioni

Sulla base della documentazione raccolta nella sezione “bibliografia” e dai test e configurazioni eseguiti e descritti in questo documento, si ritiene che valga la pena indagare ulteriormente per portare a tutti gli effetti la soluzione in “produzione”.

Di seguito, un brevissimo riepilogo di quanto sopra emerso da questa fase preliminare:

  • Tier 0 dedicato.
  • Estensione del cluster Edge (aggiunta di nodi, fino a 10) o deploy di un cluster dedicato.
  • 1 Tier 0 per ogni coppia di Edge (per avere l’HA).
  • Soluzione testata.
  • VRF (Tier 0) dedicato.
  • Non necessita di aggiunta di nodi.
  • Essendo un sottoinsieme del T0 padre, ogni T0 gestisce fino a 100 VRF (100 clienti dedicati).
  • Soluzione da testare.
  • Modifica dei permessi per la gestione della rete dei clienti (Right Bundle, Global Bundle e Organizational Administrator).
  • Eventuale modifica dei permessi per l’indipendenza da parte del cliente nella creazione dei Tier 1 (Right Bundle, Global Bundle e Organizational Administrator).
  • Valutare l’impatto sulle risorse necessarie.

Bibliografia

Invia commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Chiama Ora