Il momento in cui un’infrastruttura di virtualizzazione arriva a fine ciclo raramente coincide con un guasto. Le macchine funzionano, i servizi rispondono, l’amministratore di sistema non segnala nulla di urgente. Quello che cambia è il contesto. I server hanno sette o otto anni e le condizioni di licenza dell’hypervisor sono cambiate dopo l’ultima operazione societaria del produttore. Il preventivo di rinnovo arriva con un ordine di grandezza diverso da quello dell’anno precedente. È a quel punto che una migrazione a Nutanix entra nell’elenco delle opzioni da valutare.
Il problema è che la valutazione di una migrazione a Nutanix parte quasi sempre dalla domanda sbagliata. Si chiede quanto costa, mentre la variabile che determina tutto il resto è il dimensionamento. Quanti nodi servono, su quali dati si calcolano, e che cosa succede all’infrastruttura esistente mentre il passaggio è in corso.
Nella migrazione a Nutanix tre nodi sono la soglia dell’espansione a caldo
La configurazione minima per avere tutte le funzionalità è di tre nodi. Con due nodi la piattaforma funziona, ma alcune funzioni vengono meno; con un nodo singolo si perdono i vantaggi architetturali che giustificano la scelta. Fin qui il dato è noto e viene ripetuto in ogni presentazione.
La ragione operativa è meno conosciuta e pesa molto di più. Da tre nodi in su un nodo si aggiunge o si rimuove a caldo, senza fermo dei servizi e senza degrado delle prestazioni. Sotto quella soglia il cluster non è espandibile. Nasce con la dimensione che ha e muore con quella, e per aggiungere capacità occorre svuotarlo, azzerarlo, ricostruirlo e rimettere dentro i dati. Il fermo, in quel caso, è certo.
Il secondo elemento che condiziona una migrazione a Nutanix riguarda la protezione del dato. Con il fattore di ridondanza minimo ogni blocco viene scritto due volte, su nodi sempre distinti. La perdita di un nodo non comporta perdita di dato. Questo ha una conseguenza diretta sul dimensionamento, perché la capacità grezza dei dischi non è la capacità utilizzabile. Al fattore di ridondanza si somma l’occupazione della macchina di controllo presente su ogni nodo. Va poi riservato il margine per far funzionare il cluster con un nodo in meno, sia per guasto sia per aggiornamento.
Esiste anche una via a licenza per macchina virtuale, indicata sotto le quindici o venti macchine, indipendente dal numero di nodi sottostanti. Le funzionalità non cambiano, cambia la metrica di conteggio. Per ambienti più densi la metrica resta il numero di core fisici. Questo spiega perché in fase di scelta dell’hardware la frequenza del processore conti più del numero di core.
Consumato e provisionato: il dato che raddoppia la configurazione
È l’errore più frequente e il più costoso. Gli strumenti di raccolta dati leggono due valori diversi per ogni macchina virtuale: quello che le è stato assegnato e quello che consuma realmente. Dimensionare sul primo porta a comprare risorse che resteranno ferme, dimensionare sul secondo lascia margini così stretti che basta un picco simultaneo per trovarsi corti.
Su un ambiente reale a settantotto macchine virtuali la differenza tra i due scenari valeva il doppio della configurazione. Sul consumato: tre nodi a socket singolo, sedici core ciascuno. Sul provisionato: tre nodi a doppio socket, novantasei core complessivi, con richiesta di memoria e di spazio più che raddoppiata. Le due configurazioni descrivevano la stessa azienda, e la seconda significava acquistare macchine di una classe superiore per carichi che non esistevano.
Altri due valori vanno letti con diffidenza. La memoria riportata dal collettore è quella allocata dall’hypervisor, non quella effettivamente impegnata. In un caso il referente riteneva di consumarne poca e lo strumento ne indicava oltre un terabyte. La differenza si chiarisce solo guardando l’andamento su più mesi. Lo spazio disco, a sua volta, include come archivio anche unità esterne collegate all’ambiente, che nella nuova infrastruttura non esisteranno più.
Il rapporto tra core virtuali e core fisici è il terzo valore da non dare per scontato. Lo strumento applica rapporti diversi macchina per macchina in base al consumo osservato. Su ambienti poco caricati la media rilevata può scendere molto sotto il valore considerato normale. Forzare un rapporto unico e rieseguire la simulazione è il modo più rapido per capire quanto margine esiste.
I dati da raccogliere prima di quotare una migrazione a Nutanix
- L’esportazione completa dell’inventario, preferibilmente con lo strumento di raccolta che registra una settimana di attività: una fotografia istantanea non intercetta i picchi notturni dei processi batch e dei backup.
- L’elenco delle macchine spente, con la decisione esplicita su quali importare e di quali portare anche lo spazio occupato.
- L’elenco dei carichi che non vanno migrati: macchine di servizio dell’hypervisor, ambienti di collaudo, sistemi già destinati alla dismissione.
- Le macchine sovradimensionate, cioè quelle con risorse assegnate molto superiori all’uso reale nell’arco della settimana: sono il primo elenco su cui intervenire.
- L’indicazione se lo storage di partenza è locale oppure su rete dedicata, perché in quel caso il dimensionamento deve sostituire anche i controller dell’apparato esterno.
- Il vincolo di omogeneità dell’hardware: i nodi devono essere dello stesso produttore e con caratteristiche allineate. Famiglie di processore diverse limitano la migrazione a caldo tra cluster.
Che cosa resta acceso durante il passaggio a Nutanix
La domanda che blocca più progetti riguarda il fermo dei servizi. Nei percorsi seguiti da Aesir è anche quella su cui il malinteso è più frequente. Una migrazione a Nutanix da un ambiente VMware non richiede una finestra di indisponibilità proporzionale alla dimensione dell’infrastruttura, perché la copia avviene mentre tutto è in esercizio.
Lo strumento di migrazione crea una replica dall’ambiente di partenza verso il nuovo cluster e aggiorna il delta a intervalli di pochi minuti. Nel frattempo la macchina originale continua a lavorare. Quando l’amministratore decide che è il momento, spegne la macchina sulla sorgente, lascia copiare il residuo e la riaccende sul cluster nuovo: il disservizio è confinato a quel passaggio. La macchina di partenza resta disponibile con una nota di avvenuta migrazione, quindi il ritorno indietro è possibile finché non viene dismessa. Le licenze dell’hypervisor precedente vanno mantenute fino alla chiusura del cutover sull’ultima macchina. Questa sovrapposizione va messa a piano insieme alla data di scadenza del rinnovo.
Prima del passaggio definitivo si può accendere la macchina nel nuovo ambiente su una rete isolata e verificarla. Così una migrazione a Nutanix resta reversibile fino al momento del passaggio definitivo. In migrazione si possono anche modificare le risorse assegnate, rimappare le reti e rimuovere gli agenti dell’hypervisor precedente. Chi vuole procedere per gradi può mantenere l’hypervisor VMware sopra lo storage Nutanix e convertire più avanti con un riavvio progressivo nodo per nodo. La compatibilità con l’hypervisor precedente viene mantenuta anche a regime. Questa è la ragione per cui la convivenza non è una fase da attraversare in fretta. Chi sta ancora ragionando sul se, più che sul come, trova i criteri preliminari nell’analisi dedicata all’alternativa a VMware e all’iperconvergenza.
Il caso di un’infrastruttura a fine ciclo e di due scenari sul tavolo
Un’azienda con tre nodi fisici di due produttori diversi, hypervisor VMware e settantotto macchine virtuali ha aperto la valutazione di una migrazione a Nutanix. La richiesta era semplice: sostituire l’hardware arrivato a fine ciclo e chiudere il capitolo delle licenze. La memoria installata superava il terabyte complessivo, lo spazio disponibile era misto tra dischi meccanici e a stato solido, e circa metà dello spazio risultava occupato.
Il nodo è emerso alla prima simulazione. La configurazione restava contenuta se dimensionata sul consumato; raddoppiava, insieme alla classe di macchine da acquistare, se dimensionata sul provisionato. Nessuno dei due numeri era sbagliato: descrivevano due letture diverse dello stesso ambiente.
Il dettaglio delle singole macchine ha chiarito il quadro. Molte avevano una sola unità di elaborazione virtuale, il processore risultava poco impegnato. Il rapporto tra core virtuali e fisici era la metà di quello considerato normale. L’ambiente non era compresso, era sovradimensionato all’origine.
Come si è chiusa la configurazione
Su quel dato è stata costruita la configurazione definitiva. È rimasta la serie a socket singolo con sedici core, senza toccare la metrica su cui si calcolano le licenze. Sono cresciuti gli altri componenti: memoria a mezzo terabyte per nodo, dischi di taglio doppio rispetto all’ipotesi iniziale, una scheda di rete aggiuntiva, un processore a frequenza più alta a parità di core. La prova è nella logica del margine: un modello proposto dal configuratore era stato scartato perché aveva un solo disco a stato solido, quindi un punto singolo di guasto.
A decidere i tempi è stato il mercato dell’hardware. I prezzi di memoria e dischi erano in forte volatilità e i tempi di consegna superavano abbondantemente i tre mesi. La decisione è stata partire con la configurazione misurata e aggiungere semmai un nodo più avanti. Sovradimensionare oggi avrebbe significato pagare a prezzi anomali capacità che sarebbe rimasta inutilizzata. Il vantaggio dell’architettura è proprio la possibilità di aggiungere un nodo senza fermare nulla.
Insight. Una migrazione a Nutanix si decide su tre numeri e non su uno soltanto. Il consumo reale misurato su una settimana, il margine per funzionare con un nodo in meno, il ritmo con cui l’azienda prevede di crescere. Con quei tre numeri in mano il confronto tra fornitori smette di essere un confronto tra listini.
Che cosa cambia secondo il numero di nodi
| Configurazione | Che cosa resta disponibile | Il limite da conoscere prima |
|---|---|---|
| Nodo singolo | Gestione completa della piattaforma, licenza per macchina virtuale | Nessuna copia del dato su un secondo nodo e nessuna espansione a caldo |
| Due nodi | Ridondanza del dato tra i due nodi | Alcune funzioni non disponibili, e per crescere serve una ricostruzione con fermo |
| Tre nodi o più | Alta disponibilità, aggiunta e rimozione a caldo, replica verso un secondo sito | Va riservato il margine per funzionare con un nodo in meno, per guasto o per aggiornamento |
Dopo la migrazione a Nutanix, il nodo di replica si accende soltanto quando serve
La replica verso un secondo sito è compresa nel livello di licenza principale, e questo cambia la valutazione economica del disaster recovery rispetto all’architettura precedente. Si possono impostare destinazioni multiple con obiettivi di punto di ripristino differenti: un sito vicino in modalità sincrona, uno remoto in asincrona. L’appoggio può essere il proprio datacenter oppure un fornitore di servizi.
Con la licenza di ingresso l’intervallo minimo tra due repliche è di un’ora. I livelli superiori scendono nell’ordine dei quindici minuti e, al livello più alto, alla replica sincrona. Nel modello a servizio gestito le licenze si applicano su base mensile. Un nodo remoto può quindi restare acceso soltanto quando serve, invece di essere alimentato tutto l’anno.
Una precisazione utile a chi dimensiona: non è obbligatorio replicare tutte le macchine. Si sceglie il sottoinsieme che deve ripartire per primo e gli si assegna un profilo di risorse ridotto. Chi affida il cluster a un fornitore gestito trova i criteri per stabilire chi risponde del dato e chi dell’infrastruttura nell’approfondimento sul cloud gestito e sulla responsabilità dei dati.
Le domande che tornano nelle valutazioni infrastrutturali
Serve per forza hardware a marchio del produttore?
No. Nell’elenco di compatibilità figurano macchine a marchio Nutanix e famiglie dedicate di Dell, Lenovo e HPE, oltre a server generalisti verificabili componente per componente. La verifica va fatta prima dell’ordine su controller, unità di avvio, dischi, alimentatori, processori e schede di rete. Se i pezzi da sostituire diventano molti, l’acquisto di macchine nuove torna a essere la strada più lineare. Il produttore mantiene un portale pubblico con l’elenco delle piattaforme hardware supportate, e un portale riservato con la matrice di compatibilità, la matrice software e i percorsi di aggiornamento.
Si può riutilizzare l’infrastruttura di backup esistente?
Sì. Veeam è pienamente supportato sull’hypervisor nativo, con installazione su macchina virtuale oppure tramite appliance già configurata che si collega direttamente all’hypervisor e centralizza le copie. Serve la licenza specifica, analoga a quella già in uso in ambiente VMware. In aggiunta si possono sfruttare i domini di protezione della piattaforma, che definiscono che cosa replicare, dove e con quale frequenza. Chi vuole una copia non cancellabile può affiancare uno storage immutabile che espone un archivio a oggetti compatibile.
Una migrazione a Nutanix è compatibile con un gestionale critico?
La verifica va condotta con il produttore dell’applicativo, perché alcune certificazioni sono scritte sul singolo hypervisor e non sull’architettura. È un controllo che conviene chiudere all’inizio della valutazione: nella nostra esperienza è la clausola che più spesso obbliga a rivedere il perimetro. Il motivo è che un server dedicato certificato può restare fuori dalla migrazione senza compromettere il resto del progetto. Oltre milleottocento soluzioni di terze parti risultano validate sull’hypervisor nativo per protezione dati, rete e sicurezza.
Chi gestisce aggiornamenti e manutenzione dei nodi dopo il passaggio?
La piattaforma coordina in autonomia gli aggiornamenti di sistema, applicativi e di sicurezza. Mette un nodo in manutenzione, sposta i carichi sugli altri e lo rimette in servizio al termine. Il riavvio serve solo quando l’aggiornamento tocca l’hypervisor. Su un cluster a tre nodi dimensionato correttamente l’operazione avviene con i carichi in esercizio. Durante la finestra, però, il cluster resta temporaneamente senza margine per un ulteriore guasto.
L’infrastruttura può estendersi verso un cloud pubblico?
Sì, e la licenza è portabile: la stessa può essere collocata nel datacenter aziendale, presso un fornitore di servizi oppure su un cloud pubblico, spostandola quando il progetto evolve. L’unico vincolo rilevante è che sugli hyperscaler non si istanzia un nodo singolo, serve un cluster completo. Vale la pena ricordare che istanziare un cluster in cloud richiede meno di un’ora. Allestire un sito fisico comporta invece tempi di approvvigionamento che si contano in mesi.
Parliamone
Una migrazione a Nutanix si valuta bene soltanto quando il confronto avviene tra configurazioni misurate, non tra preventivi costruiti su presupposti diversi. Il lavoro che produce valore precede la quotazione. Raccogliere una settimana di dati reali, ripulire l’inventario dalle macchine che non verranno migrate, decidere se dimensionare sul consumo o sull’assegnato. Infine, mettere nero su bianco quale margine si vuole avere il giorno in cui un nodo si guasta. Aesir Srl è Partner Professional Nutanix e gestisce datacenter Tier IV proprietari in Unione Europea con replica. Opera come MSP e MSSP nello stesso perimetro contrattuale, con certificazioni ISO 9001, 27001, 27017 e 27018 e allineamento volontario a NIS2. Se desidera approfondire il tema o valutare la situazione della sua azienda, può compilare la form in fondo alla pagina oppure scrivere a support@aesir-tech.it: prenotiamo una consulenza gratuita e partiamo dai suoi numeri.