Virtualizzazione che ottimizza tutto.

Il problema dei server fisici uno per servizio

L'abitudine di dedicare una macchina a ogni servizio — uno per il gestionale, uno per i file, uno per il database, uno per l'applicativo di reparto — produce una sala piena di hardware che lavora al dieci per cento delle proprie capacità. Sono cinque garanzie da rinnovare, cinque sistemi da aggiornare, cinque alimentatori che possono guastarsi e cinque macchine da sostituire in momenti diversi. E quando una si rompe, il ripristino richiede hardware compatibile: se il modello è fuori produzione, sono giorni di fermo.

Cosa cambia concretamente

Non è solo consolidamento: cambia il modo in cui si gestiscono guasti e crescita.

• Un server virtuale è un file: si copia, si sposta, si ripristina su hardware diverso
• Migrazione a caldo tra host per manutenzione, senza spegnere niente
• Alta disponibilità: se un host cade, le macchine ripartono in automatico su un altro
• Nuovo server pronto in mezz'ora invece che in tre settimane di attesa hardware
• Snapshot prima di un aggiornamento, con rientro immediato se qualcosa non va
• Meno hardware significa meno consumi, meno calore e meno spazio in rack

Il ripristino è la ragione principale

È il vantaggio che nella pratica pesa più di tutti gli altri messi insieme. Ripristinare un server fisico significa trovare hardware compatibile, reinstallare il sistema, riconfigurare tutto e sperare che i driver corrispondano: nei casi peggiori si parla di giorni. Ripristinare una macchina virtuale significa riportare un file su un host qualsiasi e accenderlo: si ragiona in ore, spesso in minuti. Chi ha un RTO stretto — cioè chi non può permettersi di stare fermo un giorno — non ha in realtà molte alternative.

Attenzione: gli snapshot non sono backup

È l'equivoco che costa più caro. Uno snapshot è una fotografia temporanea che vive sullo stesso storage della macchina: se lo storage si guasta o un ransomware cifra il datastore, snapshot e macchina se ne vanno insieme. Serve per rientrare da un aggiornamento andato male, non per proteggere i dati. Peggio: gli snapshot dimenticati crescono senza controllo e riempiono il datastore, causando esattamente il fermo che dovevano prevenire — è una delle cause di blocco più frequenti che troviamo negli ambienti virtualizzati non gestiti.

Quando non conviene virtualizzare

Ci sono casi in cui la risposta corretta è no, e diffidiamo di chi non li nomina mai. Applicativi legati a chiavi hardware particolari o a schede di controllo di macchinari industriali; software il cui fornitore non certifica l'ambiente virtuale e in caso di problema si rifiuta di assistere; carichi che saturano da soli un host intero, dove la virtualizzazione aggiunge complessità senza vantaggi; e infrastrutture con un solo server, dove un unico host senza ridondanza sposta il rischio invece di ridurlo. In quest'ultimo caso, o si prevedono due host, o si accetta consapevolmente il compromesso.

Come procediamo

Partiamo dal rilevamento dei carichi reali: quasi sempre i server fisici esistenti sono sovradimensionati e l'host di destinazione costa meno del previsto. Dimensioniamo su misura, con margine per la crescita, e definiamo il livello di ridondanza in base al tempo di fermo che puoi tollerare. La conversione delle macchine fisiche avviene per gradi, nei fine settimana, con l'originale conservato spento finché la virtuale non è validata. Lavoriamo con VMware e Hyper-V su hardware HPE e Dell — la scelta dipende dal parco esistente, dalle licenze già possedute e dal budget, non da una preferenza nostra.