VMware Cloud Director → Proxmox VECaso anonimizzato
Un service provider lascia VMware Cloud Director e porta 40 tenant su Proxmox VE
Un provider regionale che vende cloud a PMI e studi professionali riceve il mancato rinnovo del contratto VMware. Porta quaranta organizzazioni su Proxmox VE con il portale multi-tenant NextGuard, mantenendo self-service, reti isolate e IP pubblici.
- Da
- VMware Cloud Director 10.5
- Verso
- Proxmox VE, SDN EVPN, portale multi-tenant
- Dimensione
- 40 tenant, ~600 VM
- Durata
- 7 mesi
- Tipo
- Progetto reale, anonimizzato
Il contesto
Un service provider regionale offre da anni macchine virtuali in self-service a piccole e medie imprese, studi professionali e software house del territorio. Il servizio gira su VMware Cloud Director sopra due cluster VMware vSphere con storage su SAN e rete NSX. In totale sono una quarantina di organizzazioni, circa seicento macchine virtuali, reti private per ogni cliente ed edge gateway con NAT, firewall e VPN.
All'inizio dell'anno arriva la comunicazione di Broadcom: il contratto VMware Cloud Service Provider non sarà rinnovato. Il nuovo programma è solo su invito e le licenze acquistate da altri canali non si possono usare per servire clienti terzi. Le alternative sono passare i clienti a uno dei provider rimasti oppure cambiare piattaforma prima della fine del contratto in corso. Il provider sceglie la seconda strada con un vincolo: i clienti devono continuare a gestire da soli le proprie macchine, come facevano con VMware Cloud Director. Il percorso generale è descritto nella pagina Migrazione da VMware Cloud Director.
Il problema da risolvere
Proxmox VE è un'ottima base per un cloud: cluster, alta disponibilità, Ceph, SDN, backup e API complete. Da solo però non offre ciò che un provider vende, cioè un portale in cui ogni cliente vede solo le proprie risorse, crea macchine entro le proprie quote e gestisce le proprie reti senza poter toccare quelle degli altri.
Questo strato lo fornisce il portale multi-tenant NextGuard per Proxmox VE.
L'architettura
Calcolo e storage
Due cluster Proxmox VE con Ceph su NVMe sostituiscono i cluster VMware vSphere e la SAN. I nodi VMware liberati durante la migrazione vengono reinstallati e aggiunti ai nuovi cluster.
Rete dei tenant con EVPN e VXLAN
Ogni organizzazione di VMware Cloud Director diventa una zona EVPN dell'SDN di Proxmox VE, con la propria VRF. Le reti dell'organizzazione diventano VNet in quella zona, trasportate in VXLAN. Il traffico di ogni tenant esce dal suo edge gateway, non da un'uscita comune del cluster: per questo due tenant possono usare le stesse subnet private senza conflitti, come in VMware Cloud Director.
Edge gateway con MikroTik CHR
Gli edge gateway di ogni tenant diventano router virtuali MikroTik CHR dedicati, collegati alla zona del tenant. Gestiscono NAT, regole di ingresso, IP pubblici assegnati e VPN IPsec o WireGuard verso le sedi del cliente. Ogni edge gateway è protetto dall'alta disponibilità di Proxmox VE: se il suo nodo si guasta, viene riavviato su un altro nodo in pochi minuti. Per i tenant che non possono permettersi nemmeno quel fermo, l'edge gateway diventa una coppia di CHR in VRRP su nodi diversi.
Verso l'esterno, una coppia di router di frontiera, anch'essi CHR, annuncia in BGP i blocchi pubblici del provider, che restano gli stessi.
Il portale multi-tenant
Il portale multi-tenant NextGuard, costruito sulle API di Proxmox VE, dà a ogni cliente uno spazio isolato con quote, template e reti proprie, ed è personalizzabile sulle esigenze del provider. Il cliente entra, vede solo il proprio spazio e crea le sue macchine entro la quota assegnata.
Come è andata
Mese 1, inventario e design. Esportazione completa della configurazione di VMware Cloud Director: organizzazioni, VDC, vApp, reti, regole dei gateway, IP pubblici, cataloghi e utenti. Ne nasce una scheda per ogni tenant.
Mesi 2 e 3, costruzione e pilota. Installazione dei cluster Proxmox VE, configurazione dell'SDN EVPN e dei router di frontiera, integrazione su misura con i sistemi di fatturazione e monitoraggio del provider. Tre tenant interni vengono migrati e usati per due settimane, per collaudare portale, prestazioni e procedure.
Mesi 3-6, migrazione per tenant. Un tenant alla volta, in finestre notturne concordate con ciascun cliente. Per ogni tenant si preparano la zona, le VNet e l'edge gateway, con le regole del vecchio edge gateway tradotte e verificate prima del passaggio. Le macchine vengono importate e avviate, si verificano servizi e raggiungibilità e si spostano gli IP pubblici. Al mattino il cliente riceve le credenziali del nuovo portale.
Mese 7, chiusura. VMware Cloud Director resta in sola lettura per un mese e poi viene dismesso.
Gli imprevisti
Le regole degli edge gateway di alcuni tenant contengono anni di eccezioni non documentate. Invece di tradurle una per una, si osserva il traffico reale di ogni tenant prima della migrazione e si ricostruiscono sui CHR solo le regole effettivamente usate, concordando con i clienti la rimozione delle altre.
Alcune macchine Windows molto vecchie non hanno driver VirtIO disponibili. Si migrano con controller emulati, compatibili anche se meno performanti, e si segnala ai clienti la necessità di aggiornarle.
Il risultato
Il provider esce da VMware prima della fine del contratto, mantiene i clienti e gli indirizzi IP pubblici, e continua a offrire un cloud in self-service. Non paga più licenze per core o per macchina virtuale: restano subscription Proxmox VE, licenze CHR e supporto. Ogni tenant ha reti isolate in una propria VRF, un proprio edge gateway e un portale in cui vede solo ciò che è suo, cioè le funzioni che i suoi clienti usavano ogni giorno in VMware Cloud Director.
Basata su progetti reali seguiti dal nostro team: nomi, numeri e dettagli che renderebbero riconoscibile il cliente sono stati modificati per riservatezza.
La tua situazione è simile?
Raccontaci il tuo ambiente: ti diciamo come lo affronteremmo.