Una software house unisce VM e Kubernetes passando da VMware a SUSE Virtualization

Il contesto

Una software house che sviluppa gestionali per il settore sanitario ha due infrastrutture parallele. Le applicazioni nuove nascono come microservizi su sei cluster Kubernetes gestiti con Rancher. Il resto, cioè database, versioni legacy dei prodotti installate per i clienti, ambienti di test e build, gira come circa centocinquanta macchine virtuali su VMware vSphere.

Il team infrastruttura passa metà del tempo a mantenere due mondi con strumenti diversi per monitoraggio, backup, rete e automazione. Il rinnovo VMware diventa l'occasione per chiedersi se servano davvero due piattaforme.

I vincoli

• Isolamento: gli ambienti dei diversi clienti devono restare separati, anche per requisiti contrattuali legati ai dati sanitari.
• Database critici: alcuni database di grandi dimensioni non possono essere containerizzati a breve.
• Automazione esistente: tutta la gestione dei cluster Kubernetes passa da pipeline GitOps, e il team vuole gestire le VM allo stesso modo.

L'architettura scelta

L'assessment classifica le macchine VMware in tre gruppi. Circa novanta da migrare così come sono, tra cui database, versioni legacy e strumenti di terze parti. Una quarantina di componenti applicativi che conviene containerizzare: migrano anch'essi come macchine virtuali, così VMware si spegne subito, e saranno trasformati in container nei mesi successivi. Una ventina da dismettere.

La piattaforma scelta è SUSE Virtualization (Harvester), installata su nodi nuovi con storage Longhorn e gestita da Rancher insieme ai cluster Kubernetes esistenti. Le macchine virtuali diventano risorse Kubernetes grazie a KubeVirt: si descrivono in file YAML versionati e si gestiscono con le stesse pipeline GitOps delle applicazioni. Ogni cliente ha un namespace e un progetto Rancher propri e una rete VM dedicata (VLAN); il traffico tra le reti dei clienti passa dal firewall perimetrale, con regole descritte in codice.

I container non girano direttamente sul cluster di SUSE Virtualization, dove sarebbe una funzione sperimentale: girano su cluster Kubernetes RKE2 creati da Rancher come macchine virtuali sulla stessa infrastruttura SUSE Virtualization.

Come è andata

Mese 1, assessment e design. Inventario, classificazione delle macchine, design della piattaforma, delle reti e delle regole di isolamento.

Mese 2, deploy e pilota. Installazione di SUSE Virtualization, integrazione con Rancher e con il monitoraggio Prometheus esistente. Pilota con gli ambienti di build e test, importati da vCenter con il componente di importazione da VMware della piattaforma, che lavora a macchina spenta.

Mesi 3-4, migrazione. Le macchine dei clienti migrano per gruppi, un cliente alla volta, con finestre concordate. I database più grandi passano con una replica applicativa verso la nuova macchina e un breve fermo per il cambio del primario, così il fermo non dipende dalla copia dei dischi.

Mese 5, chiusura e modernizzazione. VMware vSphere viene dismesso. Il team di sviluppo inizia a containerizzare i primi componenti della lista, su cluster RKE2 creati da Rancher come VM sulla stessa infrastruttura.

Gli imprevisti

Alcune macchine virtuali usano dischi molto grandi con snapshot VMware mai consolidati da anni. L'importazione diretta fallisce o richiede tempi inaccettabili. Gli snapshot vengono consolidati in finestre dedicate prima della migrazione e, per i dischi più grandi, si usa una copia preliminare dei dati.

Le regole firewall tra le VLAN dei clienti, all'inizio troppo restrittive, bloccano il traffico di backup verso alcune macchine. Il problema emerge nel pilota e le regole vengono corrette con eccezioni esplicite per il backup.

Il risultato

Una sola infrastruttura per macchine virtuali e container, gestita con Rancher e con le stesse pipeline GitOps. Il team infrastruttura dimezza gli strumenti da mantenere, i backup seguono un'unica politica e l'isolamento tra clienti è descritto in codice versionato e verificabile. La containerizzazione dei componenti legacy procede con i tempi dello sviluppo, senza scadenze imposte dal contratto VMware.